[アップデート] AWS CodeBuild の実行環境に AWS Lambda が選択出来るようになりました

[アップデート] AWS CodeBuild の実行環境に AWS Lambda が選択出来るようになりました

Clock Icon2023.11.10

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

いわさです。

数日前にちょっと話題になったアップデートですが、AWS CodeBuild が AWS Lambda をサポートしました。

どういうことかというと、CodeBuild は実行されると何らかのコンピューティングリソースを起動し、buildspec.yml という構成ファイルに記述された内容に従ってコマンドなどの実行を行う仕組みとなっています。
この実行環境はコンテナイメージであり、従来は EC2 上で実行されていました。

今回のアップデートでこの実行基盤に新たに AWS Lambda を選択出来るようになりました。
これによって、起動が早く柔軟にスケーリングするという Lambda の特性を活かして、起動に時間がかかったりビルドキューで待機が発生する問題を解決することが出来ます。
一方で、Lambda を使った場合にはいくつかの制限事項があります。いくつかというか結構あります。

今回いくつかの既存プロジェクトで使ってみようとしたところ、制限事項の問題で Lambda に移行出来ないケースがいくつかありました。
この記事では CodeBuild on Lambda で気をつける点をまとめてみましたので紹介したいと思います。

Lambda の設定方法

CodeBuild の環境の設定方法を先に確認します。
従来(EC2)の場合はオペレーティングシステムやランタイム、イメージを選択していました。

今回のアップデートで次のように、マネージド型イメージを使う場合に コンピューティングに Lambda を選択することが出来るようになっています。
Lambda の場合に選択出来るオペレーティングシステムは Amazon Linux のみで、ランタイムは次の 6 つから選択する必要があります。

なお、サポートされているツールはドキュメントでは以下となっています。

  • AWS CLI v2
  • AWS SAM CLI
  • git
  • go
  • Java
  • Node.js
  • Python
  • pip
  • Ruby
  • .NET

この時点でわかる点として Windows コンテナは使えないので、例えば .NET Framework アプリケーションなど Windows 環境でのビルドなどには引き続き EC2 を使う必要があります。

また、環境の追加設定については Lambda の場合だと次のような設定が可能です。
コンピューティングのメモリと環境変数の指定が可能なのですが、VPC の構成を行うことは出来ません。

そのため、以下の記事のように VPC 環境で CodeBuild を実行する必要がある場合も引き続き EC2 を使用する必要があります。

速度を比較してみる

今回次のような .NET ランタイムバージョンを確認するような buildspec を用意し、実行時間を確認してみました。最小の構成という感じです。

version: 0.2
phases:
  build:
    commands:
      - dotnet --version

EC2 の場合は通常の Amazon Linux 2 を、Lambda の場合は次のように .NET ランタイムを選択しました。
.NET ランタイムのバージョンは本日時点ではdotnet6の x86_64 と ARM が提供されてました。

Lambda の場合は 11 秒で終了しました。速い、確かに体感的にもかなり速いです。

内訳はこんな感じでした。

続いて EC2 の場合ですが、31 秒かかりました。3 倍かかってますね。

内訳を見てみると、半分以上をプロビジョニングの時間が占めていました。
今回は最低限のビルドステップですが、テスト実行とか大きめのビルドでも試してみたいところです。

対応しているランタイムを選ぶ必要がある

ちなみにですが、EC2 の場合あまり意識してなかったと思いますが、Lambda の場合は適切なランタイムを選択する必要がありますので注意が必要です。
次は間違って Java ランタイム環境でdotnetコマンドを実行し怒られた様子です。

Lambda を採用できないパターン

こちらの公式ドキュメントに制限事項が記載されており、先程紹介した Windows コンテナや VPC がサポートされていない点も記載されています。

特権付与モードがない

EC2 実行環境の場合は特権付与モードで起動することが出来ましたが、Lambda の場合は特権付与モードがありません。
そのため Docker ビルドあるいは、yum などの昇格されたアクセス権限が必要な場合は、別のツールの利用を検討するか EC2 環境で実行する必要があります。

大阪リージョンでは Lambda 未サポート

Lambda 実行環境は CodeBuild が使える全リージョンでサポートされているわけではありません。
日本の場合だと東京リージョンでは使用出来ますが、大阪リージョンでは使うことが出来ません。

GitHub Actions が使えない

以前のアップデートで、CodeBuild で GitHub Actions と Spec フェーズがサポートされました。

ドキュメントの制限事項では見当たりませんでしたが、試してみたところ Lambda 環境ではサポートされていないようでした。

タイムアウトある

ドキュメントに記載のとおりランタイムの実行時間に 15 分の上限があります。
実際に試してみたところ、15 分弱でビルドフェーズがタイムアウトになりました。

大きなプロジェクトだと、ビルドやテストで合計 15 分を超えることは有り得ると思います。
分割可能な範囲で CodeBuild プロジェクトを分割するか、あるいは EC2 環境を使用するのが良いです。

さいごに

本日は AWS CodeBuild の環境で AWS Lambda がサポートされたので、注意点などをまとめてみました。

確かに速かったです。
ただ、条件によく使う機能があったりと個人的には採用出来ないシーンもまぁまぁあるなという感じがしました。
Lambda タイムアウトが起きない範囲でビルド時間を短縮したい場合は、試す価値ありですね。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.